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This application is related to co-assigned applications 
all of which are incorporated herein by reference: 

lerial Number 09/154,385 entitled "METHOD OF INITIALIZING 
A CPU OSRE FOR EMULATION" filed September 16, 1998; and 
the following contemporaneously filed applications: 

Serialy Number {TI-28928P) , entitled "EMULATION 

SUSPEND MODe\jITH DIFFERING RESPONSE TO DIFFERING CLASSES OF 
INTERRUPTS " ; 

Serial NumBer (TI-28929P) , entitled "EMULATION 

SUSPENSION MODE WriH STOP MODE EXTENSION" ; 

Serial Number \ (TI-28930P) , entitled "EMULATION 

SUSPEND MODE HANDLING MULTIPLE STOPS AND STARTS"; 

Serial Number \ (TI-28931P) , entitled "EMULATION 
SUSPEND MODE WITH FRAME CONTROLLED RESOURCE ACCESS " ; 

Serial Number (TKr-28932P) , entitled "EMULATION 

SUSPEND MODE WITH INSTRUCTION JAMMING" ; 

Serial Number . (TI-Z8933P) , entitled "SOFTWARE 

EMULATION MONITOR EMPLOYED WITH HARDWARE SUSPEND MODE" ; 

Serial Number (TI-28934^) , entitled "EMULATION 

SYSTEM WITH SEARCH AND IDENTIFICATION\OF OPTIONAL EMULATION 
PERIPHERALS" ; 

Serial Number (TI-28935P) , entitled "EMULATION 

SYSTEM WITH ADDRESS COMPARISON UNIT AND DATA. COMPARISON UNIT 
OWNERSHIP ARBITRATION"; and \ 

Serial Number (TI-28936P) , entitled "EMULATION 

SYSTEM WITH PERIPHERALS RECORDING EMULATION FRAME WHEN STOP 
GENERATED" . 
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TRrHNTCAT. FTRT.D OF THE TNWNTTON 

The technical field of this invention is complex 
integrated circuits including embedded digital processor cores 
and more particularly in circuit emulation of integrated 
circuits with embedded digital processor cores. 



RArKOPDTTTTO OF THF TNVENTTON 

Programmable digital processors such as microprocessors 
and digital signal processors have become very complex 
machines. Testing these programmable digital processors has 
also become complex task. It is now common for semiconductor 
manufactures to build single integrated circuit programmable 
digital processors with millions of transistors. The current 
trend is to devote many of these transistors to on-chip cache 
memories. Even so, the number of logic circuits and their 
complex relationships makes testing such integrated circuits 
an increasingly difficult task, 

A trend in electronics makes this testing problem more 
difficult. Single integrated circuit programmable digital 
processors are becoming more and more of the electronics of 
many end products. A single integrated circuit used in this 
way typically includes a programmable digital processor, read 
only memory storing the base program, read/write memory for 
operation and a set of peripherals selected for the particular 
product. This trend is known as system level integration. In 
the ultimate system level integration, all the electronics are 
embodied in a single integrated circuit. This level of 
integration is now achieved in electronic calculators. Many 
electronic calculators consist of a single integrated circuit. 



- 2 - 




TI-28937 2/19/99 

a keyboard, a display, the battery or solar panel power source 
and a plastic case. Such integration provides less 
"visibility" into the operation of the programmable digital 
signal processor. Because the address and data busses of the 
5 digital processor are no longer brought out the device pins, 
it is more difficult to determine the behavior of the embedded 
processor from external connections. 

Another trend in electronics makes this testing problem 
more difficult. Many new product applications require 
10 differing types of processing. Often control processes and 
user interface processes are better handled with a different 
programmable digital processor than digital signal processes. 
An example is wireless telephones. Many coding/decoding and 
filtering tasks are best handled by a digital signal processor 
15 (DSP) . Other tasks such as dialing, controlling user inputs 
and outputs are best handled by microprocessors such as a RISC 
(Reduced Instruction Set Computer) processor. There is a- 
trend for a system integrated circuit to include both a RISC 
processor and a DSP. These two processors will typically 
20 operate independently and employ differing instruction set 
architectures. Thus there may be more than one programmable 
digital processor on a single integrated circuit, each having 
limited visibility via the device pins. 

Another problem is product emulation when employing these 
25 priQgrammable digital processors. Product development and 
debugging^^is best handled with an emulation circuit closely 
correspondingtt><l;iie actual integrated circuit to be employed 
in the final producb>^^^^In circuit emulation (ICE) is in 
response to this need. An int^g^^^ted circuit with ICE includes 
auxiliary circuit not needed in the^^op^ating product included 
solely to enhance emulation visibility. IrT^hetypical system 
level integration circuit, these emulation circurE"§-'--"-use only 
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a very small fraction of the number of transistors employed in 
Lerati nqcircuits . Thus it is feasible to include ICE 
circuits in allin^^egxa£ea"~clircu^ Since every 

integrated circuit can be used for emulationT^i^-ventory and 
manufacturing need not differ between a normal product anc 
emulation enhanced product. 

As a result of these trends there is a need in the art 
for integrated circuits which are easier to test and easier to 
emulate . 
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SUMMARY OF THE TNVF.NTTON 

This invention invloves emulation communications via a 
t^Bt....,^cess port and boundary- scan architecture providing 
serial a&e€t^ to a serial connection of a plurality of 
5 registers disposed in a plurality of modules. One of the 
modules is selected ror communication. Nonselected moduled 
are made nonresponsive to^-d^a on the serial connection. The 
external emulation hardware silpRlys a serial signal having a 
first logic state for a number of^^i^les greater in number 
10 than a number of bits' of the serial conne^c4:ion of registers to 



the test access port. The the emulation harsiware supplys a 
start bit having an opposite logic state. The selected module 



detects the start bit and stores the next predetermined number 
of data bits. These bits could be data bits to be stoixed in 



15 a program visible data register or bits interpreted as\an 
instruction for execution by the module. The selected module^ 
may transmit return communications via the serial scan path 
using the same format. 
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BRIEF DEfiCRTPTTON OR TMK DPAWTMH.q 

These and other aspects of this invention are illustrated 

in the drawings, in which: 

Figure 1 illustrates the environment of the debugging 
5 system of this invention which is known in the art ; 

Figure 2 illustrates the known 14 -pin JTAG header used to 

interface the target system to the access adapters- 
Figure 3 illustrates an emulation level view of the 

target system; 

10 Figure 4 illustrates an electrical connection view of the 

coupling between the access adapter and the target systems- 
Figure 5 illustrates the possible operation states in the 
debugging environment of the preferred embodiment of this 
invention; 

15 Figure 6 illustrates the typical scan-in data used to 

program an initial state of a complex integrated circuit in 
the prior art; 

Figure 7 illustrated the preferred embodiment of the 
alternate data transfer protocol of this invention; and 
20 Figure 8 illustrated in block diagram form protocol 

multiplexing hardware in accordance with this invention. 
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DETATTiRD DKSCRTPTTON OF PRKFKPPED F.MPjQDTMFNT.q 

Figure 1 illustrates the environment of the debugging 
system of this invention. This environment connects high 
level debugging software executing on a debug host computer 1 
5 to a low level debug interface supported by the target system 
3 . In this invention the target system 3 may include more 
than one programmable digital processor and possibly more than 
one such programmable digital processor on a single integrated 
circuit. In this application the term programmable digital 

10 processor is meant to encompass devices commonly knovm as 
microprocessors, microcontrollers and digital signal 
processors . The target system 3 provides a standard interface 
to the access adapter 2 . 

Debug host computer 1 consists of a computer, for example 

15 a PC, running a CPU core specific software debugger as one of 
its tasks. The debug host computer 1 allows the user to issue 
high level commands such as setting breakpoint, single 
stepping the programmable digital processor in target system 
3 and displaying the contents of a memory range. 

20 Access adapter 2 is a combination of hardware and 

software that connects the debug host computer 1 to target 
s^^SL^m 3. Access adapter 2 utilizes one or more hardware 
interfa^re-s and/or protocols to convert messages created by 
user interf acfe^^ommands of debug host computer 1 into debug 

25 commands operablebn target system 3. Access adapter 2 can be 

/7 either loosely coupleS>sQr tightly coupled to the debug host 
J computer 1. In the case or^a^PC host computer, access adapter 
3 can be an XDS 510 scan controlTi^r attached directly to the 
PC bus. This implements a tightly^^eiQupled configuration 

30 requiring the PC to perform even the lowefet^^level actions 
necessary to manage debug activity. In loos^iv coupled 
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configurations, debug host computer 1 CPU communicates with 
another processor over a high bandwidth interface such as a 
SCSI, LAN or other interface • An example of this is a XDS 
510WS controller connected to the target system debug 
5^ TrTtszi^ce and to the PC through a SCSI port. In this case 
access a^&pt^ 2 is a debug subsystem manager and handles the 
i) detailed manipulrat^on of the target debug capability, and 
y / debug host computer 1 sfeiadhigh level commands to the debug 
^ j subsystem. Access adapter 2 rettw^is data and error conditions 
^10 to debug host computer 1. Current Pt>-Q^rating systems may 
not be able to service the low level deBtig^requirements 
continuously. Thus it may be advantageous to par^C^il^on the 
problem into the display and user interface and cont^l 
sections. 

15 The target system 3 contains one or more programmable 

digital processor cores. The programmable digital processor 
core(s) contain hardware designed explicitly to ease 
debugging. This special hardware of target system 3 is the 
lowest element of the system debug environment 10. The 

20 programmable digital processor core debug facilities allow the 
user to control the program execution, examine or change 
system memory, core CPU resources in real-time. 

The interface of access adapter 2 to target system 3 is 
preferably an extension to the IEEE 1149.1 (JTAG) test 

25 standard. The JTAG standard includes 5 primary signals known 
as nTRST, TCK, TMS, TDI , and TDO. The JTAG standard typically 
employs three additional signals Test Clock Out (TCKO) , the 
target supply (Vdd) and ground (GND) . The preferred embodiment 
of this invention also employs the two extension signals nETl 

30 and nETO . Table 1 lists these signals, states whether the 
signal is an input, an output or both, and gives the 
descriptive name of the signal. 
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Type 
j.npuu/uuLpuL 


Description 


nTRST 


I 


Test Logic Reset Not 


TCK 


I 


Test Clock 


• TMS 


I 


Test Mode Select 


TDI 


I 


Test Data Input 


TDO 


0 


Test Data Output 


TCKO 


0 


Test Clock Out 


PD(Vdd) 


I 


Target Power Supply 


GND 


I/O 


Ground 


nETl 


I/O 


Emulation and Test 1 Not 


nETO 


I/O 


Emulation and Test 0 Not 



Table 1 

The signal nTRST is called Test Logic Reset Not. A low 
applied to this pin causes all test and debug logic in the 
15 target device to be reset along with the IEEE 1149.1 
interface . 

The signal TCK is called Test Clock. This signal is used 
to drive the IEEE 114 9.1 state machine and logic. The same 
TCK supplied to the target device is supplied to this pin. 
20 The signal TMS is called Test Mode Select. This signal 

directs the next state of the IEEE 1149.1 test access port 
state machine. 

The signal TDI is called Test Data Input. This signal is 
the scan data input to the target device . 

25 The signal TDO is called Test Data Output. This signal 

is the scan data output of the target device. 

Figure 2 illustrates a 14 -pin JTAG header used to 
interface target system 3 to access adapter 2 . The ' JTAG 
header requires three additional pins, and further includes 

30 two extension pins. The signal TCKO is called Test Clock Out. 
This signal is a test clock supplied by the scan controller to 
the target system. This test clock can be used as the system 
TCK source, or it can be ignored with the TCK source being 
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generated by the target system. In many target systems, TCKO 
is simply connected to TCK and used as the test clock. The 
PD(Vdd) is called the Target Power Supply. This is used as a 
power detect input to access adapter 2 . The JTAG header also 
includes • ground connections. 

The preferred embodiment of this invention includes an 
eoctension to the JTAG interface. Two pins nETO and nETl serve 
as a^twQ.c>in trigger channel function. This function 
supplements the^serial access capability of the standard 
interface with contirnuQus monitoring of device activity. The 
two added pins create debug^acid test capabilities that cannot 
be created with the standard iiot^is^^ce. The nETO signal is 
called Emulation and Test 0 Not. This^s^anal helps create a 
trigger to channel zero. Similarly, the nETl-"sianal is called 
Emulation and Test 0 Not. This signal helps creat^^-a^rigger 
to channel one. These channels will be further explaiia^d 
below. 

Figure 3 illustrates an emulation level view of target 
Si^^s^tem^.^ Target system 3 may include plural devices 11, 13 
and 15. Fi^m?e...,..3illustrates details of example device 13 
which includes plur^ajT'lTfegaDaodules 21, 23 and 25. Figure 3 
illustrates details of exampl^^^^^jnegamodules 23 . Example 
megamodule 23 includes debug and tesB^"-ieoix£r;ol unit 3 0 and 
plural device domains. These device domains incTuae-^c^ntral 
processing unit (CPU) core 31, analysis unit 33, memory 35 a^d 
debug/test direct memory access (DT_DMA) unit 37. 

Debug and test control unit 30 contains the IEEE 
interface. It provides a bridge between the Extended IEEE 
Interface and the debug and test capability distributed 
through the domains. Debug and test control unit 30 can 
independently control by the domains 31, 33, 35 and 37. In 
other words, one or more domains can be scanned or controlled 



- 10 - 



TI-28937 



continue operate in 



2/19/99 
their normal 



while other domains 
functional way. 

Figure 4 illustrates an electrical connection view of the 
coupling between access adapter 2 and target system 3. Figure 
"""^-^-siiows the connections of the of the various signals of the 
JTAG he^^Eier 5 illustrated in Figure 2. All these signals are 
connected to s^s^n controller 41. The signals nTRST, TCK and 
TMS are connected^tCL two example megamodules 31- and 33. 
Figure 4 illustrates thebp^onal connection of TCKO to the 
target system clock SYSCLK. Th^^s^n input TDI connects to a 
scan input of megamodule 31. The scari^^output of megamodule 31 
supplies the scan input of eg module 33. scan output of 
meg module 33 supplies the scan output TDO. The^t^Ajo extension 
signals nETO and nETl control meg modules 31 and 33 via^erge 
unit 32. These extension signals are monitored by tel3< 
equipment 43. 

The debugging environment illustrated in Figures 1 to 4 
permit the user to control application execution by any 
progxammabla^di^ processor of target system 3 . Typical 

control processesin51rcide-:_J^eyboard directives such as run, 
halt and step; software breakpoin^^'iTS^tfig:....^ replacement; 
internal analysis breakpoint specified progra?Tr---CQunter or 
watchpoints specified by data accesses; and externa] 
generated debug events. 

Actions such as decoding a software breakpoint 
in^tJClJ^tion (DSTOP) , the occurrence of an analysis breakpoint 
or watchpoin^"^H-ASTOP) , or the occurrence of a debug host 
computer event (HSTOP)"ai:^e..j;ef erred to as debug events. Debug 
events cause execution to suspena^: — -D^bug events tied to the 
execution of specific instructions are ca]rr&d-^.^eakpoint . 
Debug events generated by memory references are^^'&aJJ^d 
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watchpoints. External debug fiv^nt g r^an ai p^ piTpp a pi^ Q X prnt-io]l_ 
Debug events cause entry into the Debug State. 

Figure 5 illustrates the possible operation states in the 
debugging environment of the preferred embodiment of this 
invention. These operation states are execute (EXE) 101, 
debug suspend (DSUSP) 102 and interrupt during debug suspend 
(IDS) 103. 

Execute state 101 corresponds to the ordinary operation 
of target device 3. In the execute state 101 instructions are 
exectrt:ed.--,.bY;^^^the programmable digital processor in normal 
fashion. Therea^"e-<ioo debug suspend conditions. 

A low logic level appliea^&D---^fejae^^ terminal or a software 
directive requesting functional run fo^^c^s^^^^the operational 
state to execute state 101. In execute state lOlTttie-pigeline 
fetches and executes instructions and process interrupts irT^ 
normal way. 

The operational state transits from execute state 101 to 
debug suspend state 102 upon a debug event. The debugging 
environment of the preferred embodiment of this invention 
allows the suspension of program execution at points defined 
by breakpoint, watchpoints, and debug software directives, 
provided the application is an allowable debug suspend window. 
In general, debug events are allowed at an instruction 
boundary, when reset is inactive and no interrupts are active. 
Program execution suspends at an instruction boundary and the 
operational state changes to debug suspend state 102. When 
any debug condition is not met, the operational state remains 
in execute state 101 and no debug event processing occurs. 
The debugging environment permits debug event processing in 
the delayed slots of delayed branch instructions. Debug 
events occurring outside the debug suspend window create a 
debug pending condition. This condition suspends program 
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execution when the application enables debug interrupts by- 
opening the debug suspend window. 

In the debug suspend state 102 background instruction 
execution is inactive. This state permits debug/ emulation 
5 visibility into the state of target device 3 while background 
execution is suspended. In debug suspend state 102, the 
program counter (PC) and status bits are generally preserved 
at their values prior- to the debug event. The PC points to 
the instruction to be executed next. When execution resumes, 
10 the instruction referenced by the PC and those following is 
fetched for execution. This is facilitated by flushing the 
front end of the pipeline upon entry into debug suspend state 
102 from execute state 101. 



15 a debug run directive. This may be either an unconditional 
run directive or a single step run directive. A single step 
run directive enters execute state 101 long enough to advance 
the instruction pipeline one stage and then returns to debug 
suspend state 102. 

20 Certain interrupts transit the operation state from debug 

suspend state 102 to interrupt during suspend (IDS) state 103. 
These interrupts are defined by a separate interrupt mask 
independent of the normal interrupt mask. Those interrupts 
defined as high priority interrupts (HPI) or foreground 

25 interrupts cause the operation state to enter the interrupt 
during suspend state 103 from the debug suspend state 102. 
The debug suspend state 102 enables high priority interrupts 
independent of the state of the global interrupt enable bit or 
of software run directives. This enables debugging of 

30 background tasks while the target device 3 continues to 
service a real time application via high priority interrupts. 



The operational state may return to execute state 101 by 
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The interrupt pipeline jam for such a high priority 
interrupt moves the operational state to interrupt during 
suspend state 103. This jam causes an extra word to be pushed 
on the stack containing the debug status describing the reason 
5 the debug suspend state 102 entry occurred. Interrupt during 
suspend state 103 differs from the execute state 101 in that 
the interrupt processing creates a thread, linking the 
interrupt execution to the debug suspend state 102 as 
described in above. A digital frame counter (DFC) is 

10 incremented upon each high priority interrupt taken. The 
high priority interrupt sets an interrupt during debug state 
bit (IDS), which is part of the CPU status. The IDS bit sets 
after the context save stores the previous value on the stack 
with the status word. When returning from an interrupt the 

15 IDS bit indicates whether to re-enter debug suspend state 102. 
If the IDS bit is set, the interrupt occurred during a debug 
suspend state 102 and the operational state should return to 
the debug suspend state 102. If the IDS bit is not set, the 
interrupt occurred during the execute state 101 and the 

20 operational state should return to execute state 101. Upon 
returning from the interrupt, the PC and status return to 
their state before the interrupt unless the interrupt service 
routine has purposely modified values on the stack. This is 
required because it is possible for multiple interrupts to 

25 occur and be serviced while the device is in debug suspend 
state 102. 

The digital frame counter is decremented upon each return 
from interrupt . This count permits the debug environment to 
track the status of the suspended foreground task. For 
3 0 example, a taken high priority interrupt may change the 
machine state and thus the current machine state would not 
reflect the suspended background task. However, if the 
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digital frame counter were zero, then the debug environment is 
assured no interrupts have not temporarily changed the machine 
state . 

The interrupt during suspend state 103 is exited at the 
5 end of the interrupt service routine. A normal end of an 
interrupt involves a return from interrupt instruction (RTI) . 
Upon execution of a return from interrupt instruction, the 
machine status is popped from the stack. As noted above, the 
interrupt during debug state bit indicates whether the 

10 interrupt occurred during execute state 101 or debug suspend 
state 102. The operational state return to the former state 
as indicated by the interrupt during debug state bit. The 
prior value of the program counter is reloaded to recover the 
prior machine status. Execution of a return from interrupt 

15 instruction also decrements the digital frame counter. 
Because it is possible to receive a higher priority interrupt 
while servicing a prior interrupt, more than one interrupt 
level may be pending. The digital frame counter indicates the 
current interrupt level. This is useful to debug processing 

20 as the machine status may be changed by the multiple 
interrupts. The debug software can read the digital frame 
counter and supply a debug level identity to identify 
currently targeted interrupt level. Execution and register 
operations target a specific debug level. Memory operations 

25 can target a specific debug level or bypass the level 
comparison. In particular, the status of the background task 
suspended on initial entry into debug suspend state 102 can 
only be reliably determined if the digital frame counter is 
. zero. The maximum number of levels of the digital frame 

3 0 counter corresponds to the size of the interrupt hierarchy. 
This data preserves a path back to the debug suspend state 102 
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when the application concludes the interrupt service routine 
with a return from interrupt instruction. 

The interrupt during suspend state 103 transits to the 
execute state 102 upon execution of an abort interrupt 
5 (ABORTI) instruction. The abort interrupt instruction would 
ordinarily be used only on detection of a unrecoverable error 
in the interrupt service routine. The path back to the debug 
suspend state is broken upon execution of the abort interrupt 
instruction. The status of the interrupt during debug state 

10- bit and the digital frame counter are ignored in this case. 
In particular, the interrupt during debug state bit is cleared 
and the digital frame counter is set to zero. This mechanism 
enables recovery to the background task when a high priority 
interrupt service routine has an unrecoverable error. 

15 Interrupts can be serviced the while the debug software 

views or modifies the CPU state. The debug state shown to the 
programmer reflects the machine state when there is no 
interrupt service routine active. The debug software works 
with on-chip debug support to ensure the high priority 

2 0 interrupts are transparent to a debug session. Likewise this 

hardware and software combination works to make debug activity 
transparent to high priority interrupt service routines. Note 
that program execution can actually be suspended in multiple 
locations if it is desired to break within a time critical 
25 interrupt while still allowing others to be serviced. 

The alternative emulation data transfer protocol of the 
preferred embodiment of this invention cooperates with a 
serial scan test technique. The preferred embodiment of this 
serial scan technique is IEEE 1149.1 also know as JTAG 

3 0 described above. 

The example system in Figure 4 shows the^ — - 
connectivity necessary for debug with one or more devices, one 
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5 

lb 



10 



15 



20 



25 



,1^ 



30 



containing a programmable digital processor core. Figure 4 
omrtrs— -sj^gnal buffering and other electrical considerations 
necessary toci~eaJ;e a functional system. In this example, 
target device 3 contaifr5-^..,:^o meg modules 31 and 33. Meg 
module 31 includes a programmabtfe--<iigital processor core while 
meg module 33 does not. The two de^rioes share a parallel 
connection to signals nTRST, TCK, and TMS>-^-<rhe scan path 
begins as TDI at the connector, enters meg module'^^34, exits 
meg module 33, and ends as TDO back at the conneetpr. 
Connections between merge unit 3 2 and pint nETl and nETCT 
create trigger channels one and zero. 

There is a problem using serial scan paths such as JTAG 
for transferring small amounts of data to or from a particular 
unit on an integrated circuit. This problem is the serial 
overhead. The serial scan model is best for loading or 
unloading all visible registers in the serial scan path. For 
test purposes this is a good system because the whole device 
can be placed in a known state relatively simply. In addition 
the whole device state can be read simply. In debugging it is 
often desirable to load or read the state of a single register 
or a small number or registers. In such a case the serial 
scan path requires more overhead than, is necessary. 

Figure 6 illustrates the data needed to completely load 
a target device. A complete target device read uses this same 
da^E^ f ogm^^. This data would typically include a prefix 
section 110 corrl'S-pQnding to registers within the serial scan 
path before the desired'^t^aglster . The data includes the data 
111 corresponding to the desi5^<register . Lastly, the data 
typically includes a suffix section---4^3 directed to data 
corresponding to register following the desln^exiregister in 
the serial scan path. It can be quickly seem thaTx£or a 
single register read or write, most of the data transfer 
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10 



15 



20 




30 



bandwidth is directed to transferring data not necessary for 
accessing the desired register. It is knovm to provide 
particular modules of the target device with a bypass 
..capability. Using such a bypass capability causes the serial 
data strearfr-feo......^edi verted from the serial scan registers of 

that module and couple3"""Tdi*:estj^ from the module ' s serial data 
input to its serial data output ! ""Tr^re*i.....so, it is often the 

case for complex products that a minimum serTalr---&Qgn path 
including the desired register to include hundreds of times 
the number of bits as that of the desired register. 

In addition to the bandwidth problem, data alignment is 
also a problem. Naturally any deviation in the serial data 
would result in an improper alignment in the data read from 
the target system or transmitted to the target system. 
Selectively using module bypasses exacerbates this problem by 
requiring careful attention to the current data path length. 

This invention proposes employing another data transfer 
prob3^1 on the serial scan path. Figure 7 illustrates this 
alternatfexc^ta transfer protocol. This data transfer protocol 
includes a r^t^t section 121 of plural bits of the same 
digital state. A^&^cond section 130 includes a start bit 131 
of the opposite digita]>^^ate and a predetermined number of 
data bits 133. Lastly, the^c^e^s a third section 140 of the 
first digital state. In the prefl^c^d embodiment the first 
digital state is all l*s and the start Bl^is a 0. All the 
module except the module including the desirecT^egister are 
made insensitive to the scan data stream. The selectTted module 
receives the data stream and searches for the start bit/\ppon 
detection of the start bit, the predetermined number of Drt^ 
is captured. 

Figure 8 illustrates in block diagram form hardware 
within each example module 200 utilizing the alternate data 
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transfer protocol. The circuit receives a serial scan input 
on line TDI and produces a serial scan output on line TDO. 
Input switch 201 and output switch 202 route the input signal 
TDI to one of a plurality of paths according to a mode input. 
The first path is bypass path 203. This bypasses all circuits 
in the module. The second path is serial scan path 204. 
Serial scan path 204 is a serial connection of all registers 
visible via the serial scan path interface in the current 
module. The third path concerns the alternate data transfer 
protocol . 

When selected as the output of input switch 201, start 
bit detect unit 210 searches for the start bit of the opposite 
digital state. If this start bit is not detected, then the 
data is coupled to one input of output switch 202. If this 
start bit is detected, then the next predetermined number of 
bits is transferred to data register IN 211. Data register IN 
211 is visible to the programmable digital processor core 220. 

Example module 200 illustrated in Figure 8 may also 
transit Nlata via this alternate data transfer protocol. 
Programmabl^SL digital processor core 200 loads the data to be 
transmitted to\data register OUT 212. Programmable digital 
processor core 2a9sthen triggers start bit generator 213 and 
selected a data transtnission mode at output switch 202. Start 
bit generator 213 produces the start bit which is selected for 
transmission to the TDO lihe by output switch 202. Output 
switch 202 then selects data^;egister OUT 212 for serial 
transmission of the predetermined nbi^jber of bits. This scheme 
is similar to that of a universal asynchronous 
receiver/transmitter (UART) with start bi>^s and fixed length 
data. Note that the data transmitted to moduQ^ may be data to 
be loaded into selected locations within the moi^le or it may 
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